Course Registration System Requirements Attributes Guidelines
Version 1.0
Revision History
Table of Contents
Requirements Attributes Guidelines The Requirements Attributes Guidelines identifies and describes the attributes that will be used for managing the requirements for the C-Registration System. In addition, this document outlines the requirements traceability that will be maintained on the project during development. The attributes assigned to each requirement will be used to manage the software development and to prioritize the features for each release. The objective of requirements traceability is to reduce the number of defects found late in the development cycle. Ensuring all product requirements are captured in the software requirements, design, and test cases improves the quality of the product. The attribute and traceability guidelines in this document apply to the product requirements, software requirements, and test requirements for the C-Registration System.
The product requirements (defined in the Vision Document [1]) will be managed using the attributes defined in this section. These attributes are useful for managing the development effort and for prioritizing the features targeted for various releases. StatusSet after the product requirements are defined in the Vision Document. Tracks progress during definition of the project baseline.
Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority. The product manager will specify the benefit of each proposed feature in terms of critical, important, or useful.
Set by the development team. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority. For the C-Registration System, effort will be defined in person days of effort. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate. On the C-Registration Project, the Project Manager will define risk in terms of high, medium, and low.
Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Vision Document into a particular baseline release. When combined with the status field, the project team can propose, record and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision Document but will be scheduled for a later release. For the C-Registration System, the features are being planned out for the first 3 releases.
The use case requirements (defined in the C-Registration Use Case Specifications [3 – 10] and the Supplementary Specification [2]) will be managed using the attributes defined in this section. These attributes are useful for managing the development effort, determining iteration content, and for associating use cases with their specific Rose models. Set after the analysis has drafted the use cases. Tracks progress of the development of the use case from initial drafting of the use case through to final validation of the use case.
Set by the Project Manager. Determines the priority of the use case in terms of the importance of assigning development resources to the use case and monitoring the progress of the use case development. Priority is typically based upon the perceived benefit to the user, the planned release, the planned iteration, complexity of the use case (risk), and effort to implement the use case.
Set by the development team. Because some use cases require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority. The Project Manager uses these effort estimates to determine the project schedule and to effectively plan the resourcing of the tasks. C-Registration Project estimates effort in Person Days (assume 7.5 hours in a workday). Set by development team based on the probability the use case will experience undesirable events, such as effort overruns, design flaws, high number of defects, poor quality, poor performance, etc. Undesirable events such as these are often the result of poorly understood or defined requirements, insufficient knowledge, lack of resources, technical complexity, new technology, new tools, or new equipment. C-Registration Project will categorize the technical risks of each use case as high, medium, or low.
Records the development iteration in which the use case will be implemented. It is anticipated that the development for each release will be performed over several development iterations during the Construction Phase of the project. The iteration number assigned to each use case is used by the Project Manager to plan the activities of the project team. The current plan is for the C-Reg Project to undergo 3-4 iterations during the Construction Phase. In each iteration the selected set of use cases will be coded and tested.
Use cases are assigned to either individuals or development teams for further analysis, design, and implementation. A simple pull down list will help everyone on the project team better understand responsibilities. Identifies the Rose use case model associated with the use case requirement. The test cases (defined in the Test Plan for the C-Registration System [11]) will be planned and tracked using the attributes defined in this section. Set by the Test Lead. Tracks status of each test case.
Records the system build in which the specific test case will be verified. The C-Registration System will be implemented in several iterations of the Construction Phase. An iteration typically requires 1-3 builds.
Individual assigned to perform and verify the test case. This simple pull down list will help everyone on the project team better understand responsibilities.
Planned test date or actual test date.
The product requirements defined in the Vision Document [1] will be traced to the corresponding use case or supplementary requirements in the Use Case Specifications [3],[4],[5],[6],[7],[8],[9],[10] and the Supplementary Specification [2]. Each product requirement traces to 1 or more use case requirements and supplementary requirements. The use case requirements defined in the Use Case Specifications [3],[4],[5],[6],[7],[8],[9],[10] and the Supplementary Specification [2] will be traced to the corresponding test cases specified in the Test Plan [11]. Each use case requirement traces to 1 or more system test cases.
|
|
Rational Unified
Process |